Gestion des runners Froggit

Froggit fournit des GitLab runners partagés pour exécuter vos pipelines CI/CD.

Ces runners permettent de lancer des jobs GitLab CI/CD sans avoir à installer votre propre infrastructure d’exécution.

Ils sont disponibles sous forme de runners d’instance, c’est-à-dire qu’ils peuvent être utilisés par l’ensemble des projets hébergés sur Froggit.

Cette page explique comment utiliser les runners Froggit, quels tags sont disponibles, comment choisir le bon runner pour vos jobs et dans quels cas ajouter vos propres runners.

Choisir rapidement le bon runner

Dans la majorité des cas, vous n’avez pas besoin de déclarer de tag dans vos jobs CI/CD.

Besoin	Configuration recommandée
Exécuter un job standard	Ne pas déclarer de tag
Lancer des tests, du lint ou un script applicatif	Ne pas déclarer de tag
Utiliser le cache GitLab CI/CD	Ne pas déclarer de tag, utiliser cache:
Exécuter des commandes Docker	Utiliser le tag docker
Utiliser explicitement Docker-in-Docker ou DinD	Utiliser docker, dind ou docker-in-docker
Utiliser un runner compatible BuildKit	Utiliser le tag buildkit
Cibler explicitement Kubernetes	Utiliser kubernetes-executor ou k8s-executor
Avoir des ressources garanties ou spécifiques	Utiliser vos propres runners ou demander des runners dédiés

tip

Pour un job standard, commencez sans tag.

Ajoutez un tag uniquement lorsque le job a besoin d’une capacité technique précise.

Principe général

Dans GitLab CI/CD, les runners exécutent les jobs définis dans votre fichier .gitlab-ci.yml.

Un job peut être exécuté :

• sans tag ;
• avec un ou plusieurs tags ;
• sur un runner partagé Froggit ;
• sur un runner de groupe ou de projet que vous avez enregistré vous-même.

Sur Froggit, pour un job standard, nous recommandons de ne pas utiliser de tag.

test:
  image: debian:12-slim
  script:
    - echo "Job standard exécuté sur un runner partagé Froggit"

Les jobs sans tag sont acceptés par les runners partagés standards.

info

Les jobs sans tag ne sont pas acceptés par les runners privilégiés permettant d’exécuter des commandes Docker, Docker-in-Docker ou DinD. Ces runners doivent être sélectionnés explicitement avec un tag adapté.

Utiliser les tags GitLab CI/CD

GitLab permet d’utiliser le mot-clé tags dans un job CI/CD pour sélectionner les runners compatibles.

Exemple :

build:
  tags:
    - docker
  script:
    - docker version

Un runner doit posséder les tags demandés par le job pour pouvoir l’exécuter.

warning

Plus vous ajoutez de tags, plus vous réduisez le nombre de runners capables d’exécuter le job.

En cas de doute, commencez sans tag pour les jobs standards.

Runners partagés Froggit

Les runners fournis par Froggit sont des runners d’instance.

Ils sont mutualisés entre tous les projets hébergés sur Froggit et permettent d’exécuter les pipelines CI/CD sans configuration supplémentaire côté utilisateur.

Froggit met à disposition plusieurs familles de runners :

• des runners standards avec exécuteur Docker ;
• des runners privilégiés pour exécuter des commandes Docker ;
• des runners compatibles BuildKit ;
• des runners Kubernetes utilisés comme capacité de débordement.

Les noms internes des runners ne sont pas documentés, car ils font partie de l’infrastructure opérée par Froggit et peuvent évoluer.

Tags disponibles

Tag	Statut	Type	Description	Usage recommandé
froggit	Actif	Informatif	Identifie les runners fournis par Froggit.	Ne pas utiliser seul pour sélectionner un runner.
shared	Actif	Informatif	Identifie les runners partagés fournis par Froggit.	Ne pas utiliser seul pour sélectionner un runner.
cache	Déprécié	Historique	Ancien tag lié à la gestion du cache.	⚠️ Ne plus utiliser dans les nouveaux pipelines.
docker-executor	Actif	Technique	Identifie les runners utilisant l’exécuteur Docker.	Usage avancé uniquement.
kubernetes-executor	Actif	Technique	Identifie les runners utilisant l’exécuteur Kubernetes.	Usage avancé uniquement.
k8s-executor	Actif	Technique	Synonyme de kubernetes-executor.	Usage avancé uniquement.
docker	Actif	Technique	Sélectionne les runners permettant d’exécuter des commandes Docker.	Recommandé pour les jobs qui utilisent Docker.
dind	Actif	Technique	Synonyme de docker, orienté Docker-in-Docker.	Possible si votre pipeline parle explicitement de DinD.
docker-in-docker	Actif	Technique	Synonyme de docker et dind.	Possible si vous voulez un tag explicite.
buildkit	Actif	Technique	Sélectionne les runners compatibles avec Docker BuildKit.	À utiliser pour les jobs déjà configurés pour BuildKit.

info

Les tags froggit et shared décrivent l’origine des runners.

Ils ne garantissent pas une capacité technique précise. Pour sélectionner une capacité, utilisez plutôt un tag technique comme docker ou buildkit.

Recommandations de sélection

Job standard

Pour un job standard, n’ajoutez pas de tag.

lint:
  image: debian:12-slim
  script:
    - echo "Lint du projet"

C’est le comportement recommandé pour les tests, le lint, les scripts applicatifs ou les tâches qui n’ont pas besoin de capacité particulière.

Job avec commandes Docker

Pour exécuter des commandes Docker, votre job doit cibler un runner compatible.

Nous vous recommandons d’utiliser le tag docker.

container:build:
  tags:
    - docker
  script:
    - docker version

Vous pouvez également utiliser l’un des tags synonymes suivants :

• dind ;
• docker-in-docker.

warning

Les runners Docker, DinD et Docker-in-Docker sont des runners privilégiés.

Ils sont accessibles à tous les projets, mais ils n’acceptent pas les jobs sans tag. Utilisez-les uniquement pour les jobs qui ont réellement besoin d’exécuter des commandes Docker.

tip

Déclarer une image docker:* dans un job ne suffit pas.

Le job doit aussi être exécuté par un runner capable de fournir l’environnement Docker attendu.

Job avec BuildKit

Pour cibler les runners compatibles BuildKit, utilisez le tag buildkit.

container:build:buildkit:
  tags:
    - buildkit
  script:
    - echo "Job exécuté sur un runner compatible BuildKit"

Cette page ne documente pas l’usage détaillé de BuildKit. Elle indique uniquement comment sélectionner les runners compatibles.

Job Kubernetes

Les tags kubernetes-executor et k8s-executor identifient les runners basés sur Kubernetes.

Sur Froggit, ces runners servent principalement de capacité de débordement.

L’infrastructure Froggit est conçue pour absorber la charge avec des runners standards et des runners Kubernetes élastiques. Selon la disponibilité des runners compatibles, GitLab peut affecter un job à un runner standard ou à un runner Kubernetes.

Dans la plupart des cas, vous n’avez pas besoin de cibler explicitement Kubernetes.

Cache CI/CD

GitLab CI/CD permet de déclarer du cache pour accélérer les pipelines.

Exemple :

test:
  image: debian:12-slim
  cache:
    key: "$CI_COMMIT_REF_SLUG"
    paths:
      - .cache/
  script:
    - echo "Utilisation d'un cache GitLab CI/CD"

Sur Froggit, le cache est conservé pour accélérer les pipelines, sans garantie de persistance longue durée.

warning

Le tag cache est historique et déprécié.

Il n’est plus nécessaire pour utiliser le cache GitLab CI/CD dans les pipelines récents car tous les runners sont maintenant reliés au cache sur Stockage Objet (S3 compatible). Il pourra disparaître à l’avenir.

Fair use

Froggit ne définit pas de quota strict sur l’usage des runners partagés.

Nous appliquons une logique de fair use, c’est-à-dire un usage raisonnable de ressources mutualisées.

Concrètement, chaque projet peut utiliser les runners partagés pour ses besoins CI/CD normaux, sans facturation à la minute ni quota fixe. En contrepartie, l’usage ne doit pas dégrader durablement la qualité de service pour les autres utilisateurs.

Un usage raisonnable correspond par exemple à :

• exécuter des tests automatisés ;
• lancer du lint ;
• construire des artefacts applicatifs ;
• construire des images de conteneurs de taille et dans un volume total raisonnable ;
• exécuter des pipelines liés au cycle de développement du projet.

Un usage non raisonnable correspond par exemple à :

• saturer durablement les runners partagés ;
• lancer un très grand nombre de jobs en parallèle sans nécessité ;
• exécuter des traitements très longs ou très consommateurs en CPU/RAM ;
• utiliser les runners pour du minage, du scraping massif ou des benchmarks de charge ;
• utiliser les runners pour un usage sans lien avec le projet hébergé.

info

Le fair use n’est pas là pour bloquer les usages CI/CD normaux.

Il permet de garantir que l’infrastructure partagée reste confortable pour tout le monde.

Si vos pipelines deviennent intensifs ou réguliers, contactez-nous afin d’étudier une solution adaptée, comme des runners dédiés.

Ajouter vos propres runners

Les clients Froggit peuvent enregistrer leurs propres runners GitLab.

C’est utile lorsque vous avez besoin :

• d’exécuter des jobs dans votre propre infrastructure ;
• d’accéder à un réseau privé ;
• de maîtriser précisément les ressources CPU/RAM ;
• d’utiliser une architecture spécifique ;
• d’isoler certains traitements sensibles ;
• de gérer vous-même vos contraintes de sécurité ou de conformité.

GitLab distingue plusieurs périmètres de runners.

Runners de groupe

Un runner de groupe est disponible pour les projets d’un groupe.

C’est le bon choix si vous voulez mutualiser un runner entre plusieurs projets d’une même organisation.

Documentation GitLab : Group runners

Runners de projet

Un runner de projet est rattaché à un ou plusieurs projets précis.

C’est le bon choix si vous voulez limiter l’usage d’un runner à un projet spécifique.

Documentation GitLab : Project runners

Installation de GitLab Runner

Pour installer votre propre runner, consultez la documentation officielle GitLab :

Installer GitLab Runner

tip

Un runner que vous administrez vous-même reste sous votre responsabilité.

Vous devez gérer son système, ses mises à jour, sa sécurité, sa supervision et sa disponibilité.

Demander des runners dédiés

Si vous avez des besoins spécifiques, Froggit peut proposer des runners dédiés.

C’est pertinent si vous avez besoin :

• D'accélerer vos exécutions de jobs
• de ressources garanties ;
• d’une capacité CI/CD importante ;
• d’un nombre élevé de jobs parallèles ;
• d’une isolation plus forte ;
• d’une architecture particulière ;
• de runners privilégiés maîtrisés ;
• d’un accompagnement sur vos pipelines CI/CD.

Pour demander un runner dédié, contactez-nous depuis la page Contact.

Bonnes pratiques

Ne mettez pas de tag par défaut

Pour les jobs standards, ne déclarez pas de tags.

C’est le moyen le plus simple de laisser GitLab sélectionner un runner partagé disponible.

unit-tests:
  image: debian:12-slim
  script:
    - echo "Tests unitaires"

Utilisez les tags seulement pour un besoin précis

Ajoutez un tag uniquement lorsque le job a besoin d’une capacité spécifique.

Par exemple :

• docker pour exécuter des commandes Docker ;
• buildkit pour utiliser un runner compatible BuildKit ;
• kubernetes-executor ou k8s-executor pour cibler explicitement Kubernetes.

Évitez les tags historiques

N’utilisez plus le tag cache dans les nouveaux pipelines.

Utilisez plutôt la configuration native du cache GitLab CI/CD avec la clé cache.

Gardez vos pipelines lisibles

Un pipeline clair est plus simple à maintenir.

Préférez :

container:build:
  tags:
    - docker

à une liste de tags trop longue :

container:build:
  tags:
    - froggit
    - shared
    - docker
    - dind
    - docker-in-docker

Plus un job demande de tags, plus il devient restrictif.

Dépannage rapide

Mon job reste en attente

Vérifiez d’abord les tags du job.

Si le job n’a pas de besoin spécifique, supprimez les tags et relancez le pipeline.

test:
  image: debian:12-slim
  script:
    - echo "Job sans tag"

Mon job Docker ne démarre pas

Vérifiez que le job cible bien un runner compatible Docker.

build:
  tags:
    - docker
  script:
    - docker version

Mes pipelines consomment beaucoup de ressources

Les runners partagés Froggit fonctionnent en fair use.

Si vos pipelines ont besoin d’une capacité importante ou régulière, contactez-nous pour étudier une solution dédiée grâce à notre page Contact